O FunnelFlux tem três principais ações relacionadas à navegação que ocorrem:
- Carregamento do link de entrada:
/fts/ - Carregamento do link de ação:
/action/x - Rastreamento de visualização de página por JS: POST para
/js/funnel
Os links de entrada são bastante rigorosos e contêm todos os dados necessários para rotear para um destino (já que você os teria gerado em nossa interface do usuário), e se funcionarem, irão exatamente para onde especificado, ignorando qualquer outro histórico contextual, pois um link de entrada é uma entrada autônoma e nova em um funil.
Nos dois últimos casos, a borda do FunnelFlux Pro usa as informações disponíveis para determinar em qual nó/página um usuário está e, no caso de ações, qual conexão percorrer.
Estes podem ser propensos a problemas se não forem configurados corretamente, então esta seção resumirá como o JavaScript e os links de ação determinam a página atual e a página/nó de origem, respectivamente.
Lógica do link de ação
Os links de ação sempre executarão a ação numerada que se estende do nó que eles acreditam que o visitante está.
Ao testar um funil e navegar por ele, é útil considerar o diagrama do funil e como cada ação resulta em você se movendo de um nó para o próximo, mantendo o controle de em qual nó você está (ou seja, o que o rastreador sabe que você está).
Considere uma situação em que você vai para uma página > clica em um link de ação > ele abre em uma nova aba. Você volta para a aba original e clica em um link novamente. Agora você está iniciando uma ação de um nó anterior que vem antes da posição atual conhecida do nó.
Considere um segundo cenário, mas onde o link de ação não abre em uma nova aba. Você então clica no botão de voltar do seu navegador, carregando a página anterior. Se não houver JS de rastreamento de visualização nesta página, o rastreador não sabe que você voltou para ela. Se você clicar em um link de ação agora, mais uma vez você está iniciando uma ação de um nó anterior.
Em ambos os casos, o rastreador precisa de algum mecanismo para determinar esses cliques repetidos, determinando o nó de origem de um clique.
Tratamento do referenciador
Ao carregar um link de ação, nossa borda verificará o referenciador.
Se este referenciador contiver um VID, a borda agora está ciente da sessão do visitante (sem precisar de cookies).
Se este referenciador contiver a URL completa da página, o rastreador pode agora combinar essa URL com nós/páginas conhecidos no funil, bem como páginas visitadas anteriormente, para determinar que o clique veio de uma página que já foi visitada (um evento necessário para que um clique exista).
Se o referenciador contiver um parâmetro n=NODE_ID na URL, o rastreador pode agora determinar com precisão o nó de origem, sem depender da correspondência da URL da página. Isso é mais específico, já que a mesma página pode ser usada várias vezes no mesmo funil (com diferentes IDs de nó), ou uma página pode ser incorporada em um iFrame onde a URL pai e, portanto, o referenciador não representa a página carregada.
É por isso que nosso JavaScript tem duas funções auxiliares:
Uma que verifica a tag <meta name="referrer"> na página e, se presente, atualiza seu valor para no-referrer-when-downgrade, e se não estiver presente, cria-a.
Uma segunda função que reescreve a localização da página atual para incluir o ID do visitante e o ID do nó atual na URL, tornando o valor completo do referenciador altamente informativo para o manipulador de links de ação.
Dado isso, deve-se evitar sempre ter atributos rel="noreferrer" adicionados aos links. Isso é algo sem sentido -- esconder informações do seu próprio sistema de rastreamento!
Nuance com páginas hospedadas em um domínio raiz
Uma nuance interessante pode surgir quando o referenciador completo não é passado.
Considere um funil que tem uma página inicial A em https://domain.com (ou seja, o domínio raiz/página inicial), que se conecta a uma segunda página B com URL https://domain.com/some-page/
No navegador, o usuário carregará a página A e navegará com sucesso para a página B.
Na página B, no entanto, se o referenciador completo não for passado, o próximo clique de ação pode passar um referenciador truncado (apenas nome do host). Nossa borda então vê um clique aparentemente surgindo de "domain.com".
Exclusivamente, já que o usuário usou seu domínio raiz como uma página, este referenciador é a URL/caminho conhecido do lander anterior, então o rastreador determinará corretamente, com as informações fornecidas, que isso é de fato um clique repetido da página A.
Isso leva a um loop de redirecionamento de página A > clique > página B > clique > página B > clique página B
Injeção direta de parâmetros de URL
Outra de nossas funções auxiliares de JS detectará elementos <a> em uma página onde href contém /action, então injeta:
...&vid=VISITOR_ID&rn=CURRENT_NODE_ID
Se isso ocorrer, as informações do referenciador não são usadas, pois os parâmetros de URL diretamente especificados têm prioridade.
Pode-se argumentar que as funções de reescrita de referenciador e URL podem ser úteis -- mas este não é o caso.
Existem muitas situações em que os usuários podem adicionar código JS a uma página, mas não usam elementos <a> simples para redirecionar para a próxima página. Eles podem ter elementos <a>, mas que direcionam para outras páginas, onde não podem injetar parâmetros nessas URLs. Os redirecionamentos para URLs de ação também podem ser gerenciados por JavaScript, onde o usuário tem pouco controle ou input dinâmico.
Em qualquer caso, o parâmetro "rn" especifica explicitamente para nossa borda que um clique está vindo de um nó específico para o visitante correspondente. É a maneira mais robusta de garantir um rastreamento confiável.
Em casos avançados onde o redirecionamento para links de ação não envolve elementos <a> simples, mas manipulação JavaScript, recomendamos usar a função onDone() em nosso JS de rastreamento de visualização.
Você pode usar isso para obter o ID do nó atual e o ID do visitante, então injetar esses em quaisquer funções que controlem o redirecionamento > anexar manualmente os parâmetros de URL anteriores à URL de ação, proporcionando o mesmo benefício.
Parâmetros de ação padrão
Estes podem ser ativados ao usar o item de menu de contexto "obter link de ação" no construtor de funil.
Eles estão disponíveis apenas aqui, pois devem ser específicos para um funil e nó.
Esta alternância é apenas para a geração, não aplica nenhum efeito específico ao próprio funil/nó.
Estas URLs declaram um ID de funil e nó padrão, assim:
https://USER_DOMAIN/FUNNEL_ID/ORIGINATING_NODE_ID/action/number
É importante notar que esses valores NÃO são substituições, eles só serão usados para uma solicitação de link de ação onde nenhum valor VID é conhecido, ou seja, um visitante novo ou desconhecido.
Assim, eles funcionarão em uma janela anônima, enquanto os links de ação genéricos/universais, sem contexto, não funcionariam.
Em 99% dos casos, esses parâmetros de fallback não são usados -- mas há alguns cenários onde eles são úteis, se não críticos:
- Ao fazer envios de formulários que redirecionam através de algum terceiro antes de retornar a uma URL de redirecionamento que é definida nesse terceiro. Aqui, devido aos saltos aleatórios que você não controla, se você usasse um link de ação genérico, provavelmente carregaria e não teria informações úteis de referenciador (apenas informações do sistema de terceiros aleatório). A borda só seria capaz de usar cookies para determinar o VID (não confiável!), então os parâmetros padrão seriam importantes para pelo menos levar o usuário ao destino esperado, mesmo que sua sessão seja perdida e eles sejam desconectados de sua entrada original no funil. Se o terceiro pudesse ingerir e passar parâmetros de URL adiante, ótimo! Mas, em muitos casos, isso não está disponível...
- Ao enviar usuários para alguma página onde eles precisam clicar em um link de ação, mas por algum motivo, não é possível controlar o código da página para injetar nosso JS que ajudaria na passagem de referenciador/dados
- Quando os usuários podem pular de uma página conhecida e rastreada para algumas outras páginas e depois voltar para uma página conhecida -- por exemplo, através de algum fluxo de Webinar, onde você provavelmente perderá o rastreamento da sessão, mas ainda quer rastrear algumas ações/cliques finais e garantir que os visitantes ainda redirecionem para um destino pretendido
Em outras palavras, esses links de ação são úteis em todas as situações irritantes onde você não tem controle sobre tornar o rastreamento robusto e pode esperar zero confiabilidade de referenciador/cookies/passagem de dados, mas ainda quer que as pessoas carreguem um link que você controla em algum momento posterior.
Lógica de rastreamento de visualização de página JavaScript
O evento de rastreamento de visualização de página via nosso JS tem apenas duas fontes de dados - a URL atual (e sua string de consulta) e os atributos incorporados.
Os parâmetros de URL sempre têm prioridade. Dessa forma, uma página pode incorporar JS com IDs padrão selecionados, mas os links de entrada gerados em nossa UI sempre rastrearão conforme o esperado, substituindo esses valores.
No caso de links diretos, os parâmetros de URL da string de consulta substituem os padrões do JS.
No caso de links de redirecionamento, a página resultante é carregada sem esses parâmetros, mas com um valor vid=VISITOR_ID injetado.
Este VID é passado na solicitação POST do JS e, portanto, retorna o ID do nó já conhecido para o qual o usuário está navegando, que então substitui os padrões do JS.
Aqui estão alguns outros cenários e o comportamento resultante:
- Um link de redirecionamento carrega a página, que tem JS mas sem padrões incorporados. Aqui o VID estará presente na URL e será usado, e a URL da página será usada para determinar a página atual. Isso provavelmente corresponderá ao destino para o qual o redirecionamento foi, resultando em nenhuma visualização de página extra sendo gerada (desduplicação)
- Uma página carrega sem parâmetros de URL e JS sem parâmetros incorporados definidos. O rastreamento de visualização falhará, pois um ID de funil deve sempre ser passado -- só funcionaria se um VID estivesse presente para determinar a sessão, que conteria um ID de funil atual.
- Um link de redirecionamento carrega uma página que tem JS nela, contendo parâmetros incorporados que não correspondem à sessão/funil atual. Neste caso, o VID será conhecido e terá prioridade, então o funil não mudará. Uma visualização para a página esperada já foi gerada pelo redirecionamento, e o evento de visualização JS rastreará automaticamente com correspondência de URL. Se o JS especificar um ID de página que não corresponda à página que o redirecionamento serviu, pode causar uma visualização anômala separada se o ID de página declarado existir no funil atual (caso contrário, daria erro)
- Nenhum parâmetro de URL presente. Parâmetros incorporados são usados, mas com um ID de página especificado que não existe no funil atual. A visualização não será rastreada.
- Nenhum parâmetro de URL presente. Parâmetros incorporados usam um ID de nó que não existe no ID de funil declarado. A visualização não será rastreada.
- Nenhum parâmetro de URL presente. Um ID de página está presente, mas a URL atual não corresponde a esse ID de página. A borda honrará o ID da página, ignorando a correspondência de URL. Isso permite que o iframing/incorporação funcione conforme o esperado.